1. The Field of the Invention
The present invention generally relates to reliable messaging of Web Services. In particular, the present invention provides for an efficient transfer of messages in accordance with Reliable Messaging protocols for Web Services for flow control between two endpoints and congestion control across the network wire.
2. Background and Related Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter referred to as a “computing device” or “computing system”) to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., parsing, routing, flow control, etc.). The Open System Interconnect (OSI) model is an example of a network framework for implementing a protocol stack.
The OSI model breaks down the operations for transferring an electronic message into seven distinct layers, each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to the higher intermediate layers and then is eventually received at that application layer. The application layer—the upper most layer—is responsible for supporting application and end-user processing. Further, within the application layer there may reside several other layers (e.g., the Simple Open Access Protocol (SOAP) layer). Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer is the Transmission Control Protocol (TCP).
Web Services (WS) have been a driving force in advancing communications between computing systems and are turning the way we build and use software inside-out. Web Services let applications share data and—more powerfully—invoke capabilities from other applications without regard to how these applications were built, what operating systems or platform they run on, or what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP, XML (eXtensible Markup Language), UDDI (Universal, Description, Discovery and Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Current WS technologies offer direct SOAP-message communication between an initiator (e.g., a client) and an acceptor (e.g., a service). In the common bi-directional messaging case, a SOAP request message is sent from the initiator to the acceptor and a SOAP replay message is sent in response thereto. Another communication variant between endpoints is unidirectional message, where the initiator sends a message to the acceptor with no response.
A key benefit of the emerging WS architecture is the ability to deliver integrated, interoperable solutions. Because, however, Web Services provide various services from different business, originations, and other service providers via unreliable communication channels such as the Internet, reliability of WS becomes an increasing important factor. Reliability of WS is impacted by several factors including but not limited to, the reliability of the Web Service end points; reliability characteristics of the communication channel over which the Web Services are accessed; performance and fault-tolerance characteristics; and the extent to which Web Services can handle concurrent client access.
There have been attempts at accomplishing reliable messaging of Web Services by choosing a reliable transport protocol over which the messages (e.g., SOAP messages) are exchanged between endpoints. For example, a reliable messaging transport such as message-queues can be used to deliver messages reliably between initiators and acceptors. Message-queuing communication technologies enable applications on different systems to communicate with each other by sending messages to queues and reading messages from queues that are persisted across failures for reliability.
Although queuing systems offer a transport that can be used to carry SOAP messages reliably, there are several drawbacks to such systems. For instance, these systems offer solutions for an asynchronous operation where the requests (and possibly their responses) are transferred and processed with isolation. Accordingly, these systems are typically heavyweight in terms of resources; involving multiple intermediaries with durable transacted message stores and with considerably more complexity in deployment, programming model and management. All of this is unnecessary for reliable direct communication, and detracts from the goal of minimizing latency. Further, the program model does not directly support request-response style programming or sessions. Accordingly, the queued communication model is different from the current “interactive” Web Services model, and does not address critical “connected” scenarios and “interactive” applications. For example, it is not well suited for cases where a response is expected in a timely manner, or for cases where distributed-transaction-context need to be shared between initiator and acceptor.
There have also been attempts at defining reliable transfer layers over fundamentally unreliable transport protocols, e.g., reliable HTTP or HTTPR. A common problem, however, that plagues this solution—as well as the queuing solution—is that reliable messaging can be achieved only if the specific reliable transport protocol is used for communication between the initiator and the acceptor. The fundamental nature of Web Services calls for independence from specific vender platform, implementation languages and specific transport protocols. In a generic case, an initiator may not be able to transmit a message directly to an acceptor using a particular protocol (e.g., acceptor does not support the protocol) or the message may need to pass through multiple hops after leaving the sending node prior to arriving at that destination node. Depending on the nature of the connectivity between the two nodes involved in a particular hop, a suitable transport protocol that does not offer reliable messaging characteristics may have to be chosen.
Intermediaries may also exist at different levels in the protocol stack; and therefore not offer full end-to-end reliability. For example, transport protocols may offer reliability across lower level intermediaries (e.g., IP level intermediaries—e.g., IP routers). The transport protocol may end, however, at a SOAP intermediary or application layer. Accordingly, the transport protocol may not be able to offer reliability across that intermediary, i.e., no end-to-end reliability across the application layer.
More recently, various Reliable Messaging protocols for Web Services (hereinafter referred to as “RM-WS protocols”), e.g., WSReliableMessaging, offer solutions to the above identified-deficiencies of current reliable messaging systems. These protocols are transport agnostic connected protocols that allow messages to be delivered reliably between end-point applications in presences of software component, system or network failures. Accordingly, RM-WS protocols offer solutions for reliable, end-to-end, session-oriented communication between an initiator and an acceptor.
These RM-WS protocols are akin to TCP in that TCP offers reliable, exactly-once, in-order delivery of a stream of bytes from a TCP sender to TCP receiver across Internet Protocol (IP) routers and multiple networks. Reliable Messaging protocols for WS offer the same and more for messages (note: the unit of transfer is a message, not a byte) across multiple intermediaries (including SOAP level intermediaries), transports and connections. Although TCP and RM-WS protocols are both “reliable” protocols, because RM-WS resides at the application or SOAP layer in the OSI model, RM-WS protocols provide for reliable messaging regardless of the transport protocol used to transfer the data. Accordingly, RM-WS protocols are not tied to a particular transport or other protocol used to transfer message between endpoints.
Although a few RM-WS protocols have been around for some time there are still several drawbacks and deficiencies of these protocol specs. For example, there are currently no solutions defined by these protocols for flow control of messages between endpoints. Typically, an acceptor in a reliable message exchange has a buffer where received messages are stored for delivery to the processing application. This allows for the flexibility in the system since the processing application does not need to be available to process messages as soon as they are received. The buffer, however, is limited in capacity since any system has finite resources available to it (limited by hardware and/or software). As such, an issue may arise if the receiving application is processing the messages at a rate slower from which they are sent and/or received. In such case, the acceptor buffer will fill up and the received messages would not be read from the transport or may be dropped (which is the action of reading the message from the transport but not capturing it in the buffer for lack of space); and therefore not sending a receipt acknowledgment for that message.
Message dropping is permitted by typical RM-WS protocols and is not considered a fatal failure; since in the absence of a receipt acknowledgement from the acceptor, the initiator would retry the transfer. Retries, however, cause network and system resource waste; and therefore, a need arises for an efficient mechanism for an initiator to know how many messages it can send to the acceptor without them being dropped.
Similar to the flow control problem described above, congestion control over the network wire is also a concern. Typically, messages sent over a network are transferred over several transport connections bridged by various nodes, e.g., routers. The different transport connections may be of different speeds (e.g., a 100 mbps Ethernet connection from the initiator to a node and a 56 kbps dial-up connection from the node to the acceptor). Due to the speed differences of the transport connections, the connection from a node to an acceptor could get backed-up, meaning that the network cannot take any new content for delivery since some of the content needs to be taken off first. This means that the node has to slow down its relay transmission causing it to buffer incoming messages before it can send them to there destination. Similar to other computing resources, nodes can only buffer so many messages before they need to start dropping new incoming ones. Although buffering is an acceptable technique for handling transient's traffic spikes, to minimize latency the system should strive to minimize the amount of buffering occurring in the intermediaries. Further, other reasons for dropping messages include the number of incoming links to the node all vying for the same outgoing link, the receiver being slow in processing requests or a burst of activity at the node.
Regardless of the reason for the network dropping messages, as previously mentioned, in a reliable messaging system dropped messages need to be retried to ensure delivery. If in-order delivery is required, then processing of messages whose sequence number is higher then the dropped message would be delayed until the dropped message is received, resulting in processing inefficiency on the acceptor side. Further, retrying dropped messages results in even more messages on the link from the initiator to the node, which could ultimately result in even more dropped messages—i.e., congestion, performance hindrance and resource waste.
Accordingly, a need arises for a solution that will not only adjust for flow control but will also adapt to changes for congestion over the network wire. As can be recognized, the problem extends to scenarios where multiple nodes, e.g., routers, are employed on the path from the initiator to the acceptor. As such, the solution should not take into consideration the number of routers, since that number is unknown to the initiator and may in fact change in time. Further, the solution should also be able to adapt to changes in network bandwidth, performance and topology.